Monitoring Environmental Noise and Data Packets to Display a Transcription of Call Audio

ABSTRACT

Various embodiments provide a communication system that monitors environmental noise at a computing device. The communication system additionally monitors call audio received at the computing device. Based on the environmental noise and the received call audio, the communication system determines that a user of the computing device is unlikely to hear the received call audio when played back by the computing device. In response to determining that the user of the computing device is unlikely to hear the received call audio, the communication system visually displays a transcription of at least a portion of the received call audio.

RELATED MATTERS

This application is a continuation application that claims the benefitof U.S. application Ser. No. 15/629,160, filed Jun. 21, 2017, which isincorporated herein by reference in its entirety.

BACKGROUND

Users in loud or noisy environments often experience difficulty inhearing audio during a voice or video call. In these environments, usersare forced to ask a speaking party to repeat what was previously said,or to wait until the user is able to move to a quieter environment. Inmany situations, users are not able to ask a speaking party to wait orrepeat what was said, causing the user to miss important information.For example, a user might be teleconferencing into a meeting and unableto request that previous topics of discussion be repeated. Similarly, auser may receive a pre-recorded call from a machine without any way torequest that the machine play back previous audio. These situationscause frustration and often lead to the user immediately hanging up onthe call. Even when a user is able to request that the speaking partystop and repeat missed portions of a conversation, these requests areoften annoying to the speaking party. Thus, a user may choose not tobother a speaking party and miss important information communicatedduring a call. Thus, it is desirable to communicate call audio in amanner that does not disturb parties to the call, even if a party is ina loud or noisy environment.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

While the appended claims set forth the features of the presenttechniques with particularity, these techniques, together with theirobjects and advantages, may be best understood from the followingdetailed description taken in conjunction with the accompanying drawingsof which:

FIG. 1 is an overview of a representative environment that includes anexample implementation in accordance with one or more embodiments.

FIG. 2 illustrates a more detailed view of an example implementationincluded in FIG. 1 in accordance with one or more embodiments.

FIG. 3 illustrates an example of transcribing call audio in accordancewith one or more embodiments.

FIG. 4 illustrates a flow diagram in which transcribing call audio basedon audio quality is employed in accordance with one or more embodiments.

FIG. 5 is an illustration of an example device in accordance with one ormore embodiments.

DETAILED DESCRIPTION

Turning to the drawings, wherein like reference numerals refer to likeelements, techniques of the present disclosure are illustrated as beingimplemented in a suitable environment. The following description isbased on embodiments of the claims and should not be taken as limitingthe claims with regard to alternative embodiments that are notexplicitly described herein.

The various embodiments described herein provide a communication systemthat monitors audio quality during a call. The communication systemdetermines when it is unlikely that a user of a computing deviceimplementing the communication system will be able to hear call audiobased on environmental noise and/or delays between received data packetsincluding call audio data. When the communication system determines thata user is unlikely to hear call audio, the communication systemtranscribes received call audio into text and visually displays thetranscribed text in real-time during the call. Call audio is transcribedinto text and displayed for a user to read during the call. In someembodiments, the transcribed text is converted into synthesized speechand audibly played back so that a user can listen to otherwise inaudiblecall audio. The transcription of call audio is continued until thecommunication system determines that a user is likely to hear the callaudio, based on environmental noise and/or delays between received datapackets including call audio data.

The various embodiments described herein improve upon the state of theart by monitoring call audio and environmental noise, and automaticallytranscribing call audio upon determining that the call audio wouldotherwise be inaudible to a user. This relieves users of having to ask aspeaking party on a call to repeat previously communicated informationor waiting to communicate with the speaking party at a later time. Inthis manner, the user experience with voice and video calls is improvedbecause the user can communicate in loud and noisy environments thatwould otherwise prohibit such communications. As such, the possibilityof missing information communicated in a call is significantly reduced.

In the following discussion, an operating environment is described inwhich the inventive embodiments described herein can be employed.Following this, various embodiments for transcribing call audio based onaudio quality are described.

Example Environment

FIG. 1 illustrates an example operation environment 100 in accordancewith one or more embodiments. Environment 100 includes computing device102, which is in the form of a mobile phone, as illustrated in theenvironment 104. However, computing device 102 can be configured as anyother suitable type of computing device without departing from the scopeof the claimed subject matter. In the illustrated environment 104, auser of the computing device 102 is using the computing device 102 toconduct an audio call with at least one different user located remotelyfrom the environment 104, such as users of the client devices 116. Theillustrated environment 104 represents a loud and noisy environment,where environmental noise occurring from other users' in the illustratedenvironment 104 may interfere with the user of computing device 102 frombeing able to hear audio during the call.

Among other things, the computing device 102 includes a communicationsystem 106, which represents functionality that determines when a userof the computing device 102 is unlikely to be able to hear call audioand visually displays a transcription of the call audio so that the usercan understand what is being communicated, as further described herein.For discussion purposes, communication system 106 is illustrated as asingle system, but communication system 106 can be implemented using anysuitable combination of hardware, software, and/or firmware.

Communication system 106 includes audio quality module 108 that is usedto monitor environmental noise at the computing device 102, monitor callaudio received at the computing device 102, and determine whether a useris likely to hear the call audio received at the computing device basedon the monitored environmental noise. As described herein, the audioquality module 108 is configured to determine whether a user ofcomputing device 102 is likely to hear received call audio by comparingenvironmental noise from the environment 104 against audio parametersstored in audio parameter table 110. Audio parameter table 110 includesinformation describing various threshold levels for call audio quality.For instance, audio parameter table 110 may specify a threshold level ofenvironmental noise that indicates when a user of computing device 102is unlikely to hear received call audio. Alternatively or additionally,audio parameter table 110 may specify a threshold level of data packetlatency between received data packets that include call audio data.Thus, the audio quality module 108 is configured to monitor receivedcall audio, monitor environmental noise, and compare the monitoredinformation against the audio parameter table 110 to determine whether auser is likely to hear received call audio in a variety of environments.

The communication system additionally includes microphone 112 andspeaker 114. Microphone 112 is configured to detect audio received atthe computing device 102, such as speech from a user of the computingdevice 102, environmental noise generated from the environment 104, andso on. The speaker 114 is configured to play back call audio received atthe computing device 102 so that a user of the computing device cancommunicate with different parties to the call. Using the techniquesdescribed herein, the communication system 106 is configured totranscribe call audio into displayable text so that a user of thecomputing device 102 can communicate over a call even in loud and noisyenvironments. In some embodiments, the communication system 106 uses adedicated processor for transcribing call audio into displayable text toexpedite the transcription. In this manner, the communication system isconfigured to display transcribed text for received call audio inreal-time.

For instance, the audio quality module 108 may monitor environmentalnoise generated by the environment 104 and received by the microphone112 of the communication system 106. In the illustrated environment 104,environmental noise may include noise generated by other users in theenvironment that is audibly detected by the microphone 112. As describedherein, environmental noise refers to any noise that is detectable bythe microphone 112 other than speech that is communicated by a user ofthe computing device 102. In implementations, speech communicated by auser of the computing device 102 is intended for communication during acall to one or more different users that are located remotely from theenvironment 104, such as different users of client devices 116. Speechis detected by the microphone 112 and translated into audio data, whichis then communicated to the client devices 116 via the network 118.Although illustrated as communicating with three client devices 116,such as in a four-way conference call, this illustration is not intendedto be limiting, and any number of client devices 116 may be involved ina call with computing device 102.

Network 118 may include a local area network (LAN), a wide area network(WAN), a metropolitan area network (MAN), a telephone network, such asthe PSTN, a cellular network, a Wi-Fi network, an intranet, theInternet, an optical fiber (or fiber optic)-based network, an enterprisenetwork, a carrier network, a service provider network, or a combinationof networks. In one example implementation, network 118 may include anopen network. An open network may include a network of applications,devices, and/or systems that follows industry protocols and therebycreate an environment of total interoperability. This means that any newprotocol-based products (e.g., for the open network) may automaticallybe compatible with other compliant products, applications, devices,and/or systems, with no additional programming or interfaces needed.

FIG. 2 illustrates an expanded view of computing device 102 of FIG. 1with various non-limiting example devices including: smartphone 102-1,laptop 102-2, television 102-3, desktop 102-4, tablet 102-5, andwearable device 102-6. Accordingly, computing device 102 isrepresentative of any suitable device that facilitates audio calls andincorporates audio call quality monitoring capabilities by way ofcommunication system 106. Computing device 102 includes processor(s) 202and computer-readable media 204, which includes memory media 206 andstorage media 208. Applications and/or an operating system (not shown)implemented as computer-readable instructions on computer-readable media204 can be executed by processor(s) 202 to provide some or all of thefunctionalities described herein. To facilitate transcribing call audiobased on audio quality, computing device 102 includes microphone 112 andspeaker 114. Although not shown in FIG. 2, computing device 102additionally includes a display device for displaying transcribed callaudio, as discussed in further detail with respect to FIG. 3.

As illustrated in FIG. 2, portions of communication system 106 arestored on computer-readable media 204: audio quality module 108 andaudio parameter table 110. However, although audio quality module 108and audio parameter table 110 are illustrated here as residing oncomputer-readable media 204, they each can alternately or additionallybe implemented using hardware, firmware, or any combination thereof.Communication system 106 also includes microphone 112, which can be oneor multiple microphones or other suitable apparatuses to capture soundat the computing device 102. Communication system 106 further includesspeaker 114, which can be one or multiple speakers to play back callaudio received at the computing device 102.

Having described an example operating environment in which variousembodiments can be utilized, consider now a discussion of transcribingcall audio based on audio quality in accordance with one or moreembodiments.

Transcribing Call Audio Based on Audio Quality

FIG. 3 illustrates a computing device, generally at 300, that includes adisplay device 302. The computing device 300 includes an application inthe form of a communication system that includes a user interface 304.In this example, an audio call is in progress between a user of thecomputing device implementing the communication system and at least oneadditional user located remotely from the computing device implementingthe communication system. While the audio call is in progress, pooraudio quality may be detected when environmental noise at the computingdevice rises to a level that overwhelms a level of the call audio beingoutput by the computing device. Alternatively or additionally, pooraudio quality may be detected when delays between sequential datapackets carrying audio data increase to a point where individual datapackets might be dropped before the audio data can be extracted andplayed back at the computing device. In these instances, the poor audioquality indicates that a user is unlikely to hear call audio played backat the computing device.

The various embodiments described herein mitigate the problemsassociated with poor audio quality scenarios, as well as others, byproviding a communication system that determines when a user is unlikelyto hear call audio and automatically transcribes call audio for displayto the user. For example, the communication system is configured tocause display of a poor audio quality user interface 306 that notifies auser of the computing device implementing the communication system whencall audio transcription is about to begin. Notifying a user that callaudio transcription is about to begin can be performed in any suitablemanner For example, the communication system may visually notify theuser by automatically displaying the poor audio quality user interface306, displaying a visual indicator in a taskbar of the computing device,displaying a notification, and so on. Alternatively or additionally, thecommunication system may audibly notify the user by playing a tone,chime, or other sound that is recognizable by the user as signifyinginitiation of call audio transcription. Alternatively or additionally,the communication system may physically notify the user by causing thecomputing device to vibrate. In this manner, even when a user is notlooking at the display device 302, the communication system can alertthe user to look at the display device to view a transcription of callaudio that would otherwise be inaudible.

After notifying the user that call audio transcription is about tobegin, the communication system displays an audio transcription userinterface 308 and a selectable control 310 to stop transcription.Although not illustrated, the communication system user interface 304may include a selectable control to initiate call audio transcription.Thus, a user of the computing device is able to initiate call audiotranscription even in scenarios where the communication systemdetermines that the user is likely able to hear received call audio. Inthe illustrated audio transcription user interface 308, call audio istranscribed into text and visually displayed. In this manner, a user ofthe computing device implementing techniques described herein is able tounderstand information being communicated via call audio that would beotherwise inaudible. In some embodiments, the text of the audiotranscription is converted into synthesized speech and played backsimultaneously with the displayed audio transcription user interface308. As described herein, this synthetic speech playback is particularlyuseful in scenarios where data packet jitter and latency would otherwiseresult in a data packet being dropped before call audio could beextracted and played back at the computing device.

Display of the audio transcription user interface 308 is continued untilthe communication system determines that the user is likely able to hearreceived call audio. Alternatively, display of the audio transcriptionuser interface 308 is continued until user input is received at theselectable control 310 to stop transcription. Upon receiving inputinstructing the call system to stop transcription or upon determiningthat the user is likely able to hear received call audio, thecommunication system removes display of the poor audio quality userinterface 306 and the audio call proceeds without transcription.

Consider now examples of determining that a user is unlikely able tohear call audio received at a computing device implementing thetechniques described herein.

Determining Audio Quality Based on Environmental Noise

In one or more embodiments, the communication system described hereindetermines that a user is unlikely able to hear received call audiobased on environmental noise received by a microphone of a computingdevice implementing the communication system. For example, when a userof the computing device participates in an audio call, the communicationsystem constantly monitors environmental noise generated from sourcesother than the user of the computing device.

The communication system may distinguish the user's speech from othernoise using a variety of techniques. For example, the communicationsystem can be trained to recognize sound waves generated by the user'svocal cords over the course of multiple voice calls and identifypatterns that can be distinguished from sounds generated from differentsources. Additionally or alternatively, the communication system can beuser-independent and configured to differentiate human speech from othersound sources using Hidden Markov Models, neural networks, and the like.The communication system determines a level of the environmental noiseand quantifies this level in terms of decibels.

The communication system is configured to constantly compare thedetermined environmental noise levels against audio parameters thatspecify a threshold level of environmental noise. This threshold levelof environmental noise can similarly be quantified in terms of decibels.As such, the communication system is made aware of a threshold levelthat, when satisfied, indicates that the environmental noise is likelyloud enough to inhibit a user's ability to clearly hear call audio.

In some embodiments, the threshold level of environmental noise isspecified by a manufacturer of the computing device implementing thecommunication system. Alternatively or additionally, the threshold levelof environmental noise is specified by the user of the computing deviceimplementing the communication system. In some embodiments, thecommunication system may periodically prompt the user for feedbackregarding whether the user is able to hear the call audio. In thismanner, the communication system can record user feedback and adjust thethreshold level of environmental noise to account for different userpreferences.

The threshold level of environmental noise can also be specified as afunction of a level of call audio received at the computing device. Forexample, the threshold level of environmental noise can be satisfiedwhen a level of the received call audio is equivalent to a level of theenvironmental noise. Alternatively or additionally, the threshold levelof environmental noise can be satisfied when the level of environmentalnoise is within a specified decibel range from the level of receivedcall audio. Thus, the communication system is configured to constantlymonitor environmental noise and determine when the environmental noisereaches a level that makes it unlikely for a user to hear received callaudio.

After determining that the environmental noise satisfies anenvironmental noise threshold, the communication system beginstranscribing received audio data to text and displaying the transcribedtext, using the techniques described herein. The communication systemcontinues to transcribe received audio data until it determines that themonitored environmental noise no longer satisfies the threshold level ofenvironmental noise. Having considered how audio quality can bedetermined based on environmental noise, consider now examples ofdetermining audio quality based on data packet latency.

Determining Audio Quality Based on Data Packet Latency

In one or more embodiments, the communication system described hereindetermines that a user is unlikely able to hear received call audioreceived in a series of data packets based on latency between sequentialdata packets, e.g., two sequential data packets in the series of datapackets. For example, calls that transmits media data (e.g., audio,video, and the like) using data packets, such as an IP MultimediaSubsystem (IMS) call that transmits media data using Real-time TransportProtocol (RTP) packets, scenarios arise where RTP packets are droppedbefore call audio can be extracted and played back to a user. Althoughdescribed with respect to an IMS call, the techniques described hereincan be implemented by any type of module or system responsible for thehandling of RTP packets. Due to network traffic or errors, data packetsare often lost during transfer between two endpoints. One approach toanticipate when a data packet might be lost is to monitor the timedelay, also described in terms of latency or jitter, betweensequentially received data packets. A greater latency between sequentialdata packets indicates that the network is overloaded and is likely todrop a subsequent data packet. Alternatively or additionally, a greaterlatency between sequential data packets may indicate that the devicereceiving data packets is dropping data packets with high jitter afterreception.

Upon receiving data packets, the communication system is configured todecode the data packets and extract audio data from the data packets.The IMS monitors latencies between received data packets and allow thecommunication system to decode data packets only when the latenciesbetween received data packets do not amount to excessive delay. However,when latencies between received data packets amount to excessive delay,the IMS drops the packets before audio data can be extracted from thedropped packets. Accordingly, using the techniques described herein, thecommunication system monitors latencies between received data packets topredict when a data packet might be dropped. Using the techniquesdescribed herein, the communication system has access to an incoming RTPstream received at the IMS of the computing device implementing thecommunication system. This enables the communication system to keeptrack of inter-packet delays, e.g., latencies between sequential datapackets.

In some embodiments, the communication system compares the monitoredlatencies between received data packets to a threshold level of datapacket latency. This threshold level of data packet latency isquantified in terms of time. As such, the communication system is madeaware of a threshold level that, when satisfied, indicates that a datapacket will be dropped rather than decoded for playback of containedaudio data. In some embodiments, the threshold level of data packetlatency is specified by a manufacturer of the computing deviceimplementing the communication system. Alternatively or additionally,the threshold level of data packet latency is specified by the user ofthe computing device implementing the communication system.Alternatively or additionally, the threshold level of data packetlatency is specified by a service provider facilitating transfer of datapackets between the computing device implementing the communicationsystem and different devices participating in the audio call. In someexamples, the threshold level of data packet latency is representativeof a latency level at which data packets are dropped by the IMS to avoidlarge end-to-end audio delays.

After determining that the monitored latency between received datapackets satisfies the threshold level of data packet latency, thecommunication system retrieves data packets from the IMS before they arede-queued and discarded. After retrieving the data packets, thecommunication system extracts audio data from the data packets andtranscribes speech from the audio data for visual display at thecomputing device implementing the communication system. In someembodiments, the communication system generates synthesized speech fromthe transcribed audio data and interjects the synthesized speech intoplayback of the audio data to fill in audio gaps that would otherwiseresult from dropped data packets. This enables the communication systemto simultaneously display transcribed audio data while playing back astream of received audio data that includes a portion of synthesizedspeech from otherwise dropped data packets.

Thus, after determining that data packet latency satisfies a data packetlatency threshold, the communication system transcribes call audioretrieved from data packets that otherwise would have been dropped, andvisually displays text of the transcribed call audio at a displaydevice. The communication system additionally or alternatively generatessynthesized speech from the transcribed call audio and interjects thesynthesized speech into playback of audio data from data packets thatwere not dropped by the IMS to fill in audio gaps for the call. Thecommunication system continues to transcribe call audio from datapackets that would have otherwise been dropped until it determines thatthe monitored data packet latency no longer satisfies the thresholdlevel of data packet latency. Accordingly, the techniques describedherein enable a user to obtain information communicated in an audio callwhen the information would have otherwise been inaudible.

Having considered various embodiments in which call audio is transcribedbased on audio quality, consider now an example method in accordancewith one or more embodiments.

FIG. 4 illustrates an example method 400 of transcribing call audiobased on audio quality in accordance with one or more embodiments. Themethod can be performed by any suitable hardware, software, firmware, orcombination thereof. In at least some embodiments, aspects of the methodcan be implemented by one or more suitably configured hardwarecomponents and/or software modules, such one or more components includedin communication system 106 of FIG. 1.

Step 402 monitors environmental noise at a computing device. Thisoperation can be performed in any suitable manner For example, a deviceimplementing the communication system 106 can use a microphone, such asmicrophone 112, to detect environmental noise, such as noise generatedby environment 104 of FIG. 1. In accordance with some embodiments,monitoring environmental noise includes determining a level ofenvironmental noise that is quantified in terms of decibels.

Step 404 monitors call audio received at the computing device. Thisoperation can be performed in any suitable manner. For example, a deviceimplementing the communication system 106 can receive call audio from atleast one remote device, such as one or more of client devices 116 via anetwork 118 as illustrated in FIG. 1. In accordance with someembodiments, monitoring call audio received at the computing deviceincludes determining a level of the received call audio that isquantified in terms of decibels.

In some embodiments, the computing device monitors latencies betweendata packets that include call audio received at the computing device atstep 406. Monitoring latencies between data packets that include callaudio is optional, as illustrated by the arrow circumventing step 406.For example, monitoring latencies between data packets that include callaudio may be performed when call audio is received via an IP MultimediaSubsystem (IMS) call. In addition to IMS calls, monitoring latenciesbetween data packets that include call audio may be performed in anytype of audio call that transmits call audio in a sequence of packets.In some embodiments, monitoring latencies between data packets includesdetermining an elapsed time between receiving two sequential call audiodata packets.

During the audio call, the computing device determines that a user isunlikely to hear received call audio when a level of the environmentalnoise satisfies a threshold level of environmental noise at step 408.For example, a current level of environmental noise determined in step402 can be contrasted against information specifying a threshold levelof environmental noise, such as information included in audio parametertable 110 of FIG. 1. In some embodiments, the threshold level ofenvironmental noise is specified by a manufacturer of the computingdevice implementing the communication system 106, and is “hard-wired”into the computing device. Alternatively or additionally, the thresholdlevel of environmental noise is specified by a user or learned from userinteractions with the computing device implementing communication system106. In some embodiments, the threshold level of environmental noisechanges as a function of a level of the call audio received at thecomputing device.

Alternatively or additionally, the computing device determines that auser is unlikely to hear received call audio when a latency between twosequential data packets satisfies a threshold level of data packetlatency. For example, a latency between sequential data packetsdetermined in step 406 can be contrasted against information specifyinga threshold level of data packet latency, such as information includedin the audio parameter table 110 of FIG. 1. In some embodiments, thethreshold level of data packet latency is specified by a manufacturer ofthe computing device implementing the communication system 106.Alternatively or additionally, the threshold level of data packetlatency is specified by a user of the computing device implementingcommunication system 106. Alternatively or additionally, the thresholdlevel of data packet latency is specified by a service providerfacilitating transfer of call audio between the computing deviceimplementing communication system 106 and at least one different device,such as client devices 116 of FIG. 1.

In response to determining that a user is unlikely to hear received callaudio via at least one of steps 408 or 410, the computing devicevisually displays a transcription of the call audio at step 412.Transcription of the call audio may be performed using any suitabletechnique for extracting speech characteristics from audio andtranslating the speech characteristics into text. In some embodiments,the computing device additionally generates a notification to inform auser of the computing device that a display of transcribed audio isabout to begin. For example, the notification may include at least oneof a visual notification, an audible notification, or a physicalnotification.

In some embodiments, the computing device generates synthetic speechfrom the transcription of the call audio and plays back the syntheticspeech at the computing device at step 414. Generating and playing backsynthetic speech is optional, as illustrated by the arrow circumventingstep 414. Alternatively or additionally, the computing device maygenerate synthetic speech from the transcribed text and play back thesynthetic speech simultaneously with the display of transcribed callaudio. In this manner, the computing device implementing communicationsystem 106 provides both visual and audible information describingreceived call audio that would otherwise be inaudible.

At step 416, the computing device ends display of the transcription ofthe call audio. The computing device may end display of thetranscription in response to determining that a user is likely able tohear call audio received at the computing device. For example, thecomputing device implementing communication system 106 may determinethat a user is likely able to hear call audio when environmental noiseno longer satisfies the threshold level of environmental noise.Alternatively or additionally, the computing device implementingcommunication system 106 may determine that a user is likely able tohear call audio when a latency between sequential data packets includingcall audio no longer satisfies the threshold level of data packetlatency. Alternatively or additionally, the computing deviceimplementing communication system 106 may determine that a user islikely able to hear call audio in response to receiving user inputindicating that the user is able to hear the call audio.

The various embodiments described herein improve upon the state of theart by monitoring call audio and environmental noise, and automaticallytranscribing call audio upon determining that the call audio wouldotherwise be inaudible to a user. This relieves users of having to ask aspeaking party on a call to repeat previously communicated informationor waiting to communicate with the speaking party at a later time. Inthis manner, user experience with voice and video calls is improvedbecause the user can communicate in loud and noisy environments thatwould otherwise prohibit such communications. As such, the possibilityof missing information communicated in a call is significantly reduced.

Having considered a discussion of transcribing call audio based on audioquality, consider now a discussion of an example device which caninclude call audio transcription techniques based on audio quality inaccordance with various embodiments described herein.

Example Device

FIG. 5 illustrates various components of an example device 400 in whichembodiments of transcribing call audio based on audio quality can beimplemented. The example device 500 can be implemented as any of thedevices described with reference to the previous figures, such as anytype of client device, mobile phone, tablet, computing, communication,entertainment, gaming, media playback, and/or other type of electronicdevice.

The device 500 includes communication transceivers 502 that enable wiredand/or wireless communication of device data 504 with other devices. Thedevice data 504 can include any type of audio, video, and/or image data.Example transceivers include wireless personal area network (WPAN)radios compliant with various IEEE 802.15 (Bluetooth™) standards,wireless local area network (WLAN) radios compliant with any of thevarious IEEE 802.11 (WiFi™) standards, wireless wide area network (WWAN)radios for cellular phone communication, wireless metropolitan areanetwork (WMAN) radios compliant with various IEEE 802.15 (WiMAX™)standards, and wired local area network (LAN) Ethernet transceivers fornetwork data communication.

The device 500 may also include one or more data input ports 506 viawhich any type of data, media content, and/or inputs can be received,such as user-selectable inputs to the device, messages, music,television content, recorded content, and any other type of audio,video, and/or image data received from any content and/or data source.The data input ports may include USB ports, coaxial cable ports, andother serial or parallel connectors (including internal connectors) forflash memory, DVDs, CDs, and the like. These data input ports may beused to couple the device to any type of components, peripherals, oraccessories such as microphones and/or cameras.

The device 500 includes a processing system 508 of one or moreprocessors (e.g., any of microprocessors, controllers, and the like)and/or a processor and memory system implemented as a system-on-chip(SoC) that processes computer-executable instructions. The processorsystem 508 may be implemented at least partially in hardware, which caninclude components of an integrated circuit or on-chip system, anapplication-specific integrated circuit (ASIC), a field-programmablegate array (FPGA), a complex programmable logic device (CPLD), and otherimplementations in silicon and/or other hardware.

Alternately or in addition, the device can be implemented with any oneor combination of software, hardware, firmware, or fixed logic circuitrythat is implemented in connection with processing and control circuits,which are generally identified at 510. The device 500 may furtherinclude any type of a system bus or other data and command transfersystem that couples the various components within the device. A systembus can include any one or combination of different bus structures andarchitectures, as well as control and data lines.

The device 500 also includes computer-readable storage memory devices512 that enable data storage, such as data storage devices that can beaccessed by a computing device, and that provide persistent storage ofdata and executable instructions (e.g., software applications, programs,functions, and the like). Examples of the computer-readable storagememory devices 512 include volatile memory and non-volatile memory,fixed and removable media devices, and any suitable memory device orelectronic data storage that maintains data for computing device access.The computer-readable storage memory can include various implementationsof random access memory (RAM), read-only memory (ROM), flash memory, andother types of storage media in various memory device configurations.The device 500 may also include a mass storage media device.

The computer-readable storage memory device 512 provides data storagemechanisms to store the device data 504, other types of informationand/or data, and various device applications 514 (e.g., softwareapplications). For example, an operating system 516 can be maintained assoftware instructions with a memory device and executed by theprocessing system 508. Additionally, although illustrated separate fromthe computer-readable storage memory device 512, the communicationsystem 106 can be maintained as one of device applications 514. Thedevice applications may also include a device manager, such as any formof a control application, software application, signal-processing andcontrol module, code that is native to a particular device, a hardwareabstraction layer for a particular device, and so on.

Device 500 can include communication system 106, which operates asdescribed herein. The communication system 106 can be implemented in anysuitable hardware, software, firmware, or combination thereof.

The device 500 can also include one or more device sensors 518, such asany one or more of an ambient light sensor, a proximity sensor, a touchsensor, an infrared (IR) sensor, accelerometer, gyroscope, and the like.The device 500 can also include one or more power sources 520, such aswhen the device is implemented as a mobile device. The power sources mayinclude a charging and/or power system, and can be implemented as aflexible strip battery, a rechargeable battery, a chargedsuper-capacitor, and/or any other type of active or passive powersource.

The device 500 additionally includes an audio and/or video processingsystem 522 that generates audio data for an audio system 524 and/orgenerates display data for a display system 526. In accordance with someembodiments, the audio/video processing system 522 is configured toreceive call audio data from the communication system 106 andcommunicate the call audio data to the audio system 524 for playback atthe device 500. The audio system and/or the display system may includeany devices that process, display, and/or otherwise render audio, video,display, and/or image data. Display data and audio signals can becommunicated to an audio component and/or to a display component via anRF (radio frequency) link, S-video link, HDMI (high-definitionmultimedia interface), composite video link, component video link, DVI(digital video interface), analog audio connection, or other similarcommunication link. In implementations, the audio system and/or thedisplay system are integrated components of the example device.Alternatively, the audio system and/or the display system are external,peripheral components to the example device.

Although the embodiments described above have been described in languagespecific to features and/or methods, the subject of the appended claimsis not necessarily limited to the specific features or methodsdescribed. Rather, the specific features and methods are disclosed asexample implementations, and other equivalent features and methods areintended to be within the scope of the appended claims. Further, variousdifferent embodiments are described and it is to be appreciated thateach described embodiment can be implemented independently or inconnection with one or more other described embodiments.

1. A method, comprising: monitoring, using a communication system,environmental noise at a computing device; monitoring, using thecommunication system, call audio received at the computing device;determining, using the communication system, that a user of thecomputing device is unlikely to hear the call audio received at thecomputing device; responsive to determining that the user of thecomputing device is unlikely to hear the call audio received at thecomputing device, visually displaying a transcription of at least aportion of the call audio received at the computing device; and stoppingthe visual display of the transcription of at least a portion of thecall audio in response to determining that the user of the computingdevice is likely to hear the call audio received at the computingdevice.
 2. The method as recited in claim 1, wherein the monitoring theenvironmental noise is performed by monitoring background noise using amicrophone of the computing device, the background noise being differentfrom speech of the user.
 3. The method as recited in claim 1, whereinthe call audio comprises audio of a voice call or a video call.
 4. Themethod as recited in claim 1, wherein determining that the user of thecomputing device is unlikely to hear the received call audio comprisesdetermining that a level of the environmental noise satisfies athreshold level of environmental noise.
 5. The method as recited inclaim 1, wherein determining that the user of the computing device islikely to hear the call audio received at the computing device comprisesdetermining that a level of the environmental noise no longer satisfiesa threshold level of environmental noise.
 6. The method as recited inclaim 4, wherein the threshold level of environmental noise is a decibellevel specified by a manufacturer of the computing device or a user ofthe computing device.
 7. The method as recited in claim 4, wherein thethreshold level of environmental noise is dependent on a decibel levelof the call audio received at the computing device.
 8. The method asrecited in claim 1, wherein the call audio is received as a series ofdata packets at the computing device, the method further comprisingmonitoring, for each set of two sequential data packets of the series ofdata packets, a latency between the two sequential data packets.
 9. Themethod as recited in claim 7, wherein determining that the user of thecomputing device is unlikely to hear the received call audio comprisesdetermining that the latency between two sequential data packetssatisfies a threshold level of data packet latency.
 10. The method asrecited in claim 7, wherein determining that the user of the computingdevice is likely to hear the call audio received at the computing devicecomprises determining that the latency between two sequential datapackets fails to satisfy a threshold level of data packet latency. 11.The method as recited in claim 1, further comprising generating, by thecommunication system, synthesized speech of the transcription of atleast the portion of the call audio and playing back the synthesizedspeech while the transcription is displayed.
 12. One or more computerreadable media storing computer-readable instructions which, whenexecuted, perform operations comprising: monitoring call audio receivedin a series of multiple data packets at a computing device; monitoring,a latency between sequential data packets in the series of multiple datapackets; determining that the latency between a set of two sequentialdata packets in the series of multiple data packets satisfies a datapacket latency threshold; and visually displaying a transcription ofaudio data included in the set of two sequential data packets inresponse to determining that the latency between the set of twosequential data packets satisfies the data packet latency threshold. 13.The one or more computer readable media as recited in claim 12, furthercomprising visually displaying a transcription of audio data included indata packets received subsequent to the set of two sequential datapackets until determining that the latency between the subsequentlyreceived data packets no longer satisfies the data packet latencythreshold.
 14. The one or more computer readable media as recited inclaim 12, wherein the data packet latency threshold comprises athreshold amount of time between received data packets that is specifiedby a manufacturer of the computing device or a user of the computingdevice.
 15. The one or more computer readable media as recited in claim12, wherein visually displaying the transcription of audio data includedin the set of two sequential data packets comprises extracting speechdata from the set of two sequential data packets, converting the speechdata to text, and displaying the text in real-time during the receivedaudio call.
 16. The one or more computer readable media as recited inclaim 12, further comprising determining that latencies betweensequential data packets in the series of multiple data packets isapproaching the data packet latency threshold and notifying a user ofthe computing device that the visual display of the transcription ofaudio data is about to begin.
 17. The one or more computer readablemedia as recited in claim 16, wherein notifying the user of thecomputing device that the visual display of the transcription of audiodata is about to begin comprises at least one of vibrating the computingdevice, playing an audible tone from the computing device, or displayinga visual notification at a device of the computing device.
 18. Acomputing device comprising: one or more processors; and one or morecomputer readable storage media storing computer-readable instructionswhich, when executed, perform operations comprising: monitoring, using acommunication system, environmental noise at a computing device;monitoring, using the communication system, call audio received at thecomputing device; determining, using the communication system, that auser of the computing device is unlikely to hear the call audio receivedat the computing device; responsive to determining that the user of thecomputing device is unlikely to hear the call audio received at thecomputing device, generating, using the communication system,synthesized speech of the call audio and playing back the synthesizedspeech at the computing device.
 19. The computing device as recited inclaim 18, wherein determining that the level of the environmental noiseno longer satisfies the environmental noise level threshold is performedin response to receiving user input at the computing device indicatingthat a user of the device can hear the call audio from the computingdevice.
 20. The computing device as recited in claim 18, whereindetermining that the user of the computing device is unlikely to hearthe received call audio comprises: determining that a level of theenvironmental noise satisfies a threshold level of environmental noise;or determining that a latency between two sequential data packets of theseries of data packets satisfies a threshold level of data packetlatency.